'\" t
.TH "ENVIRONMENT\&.D" "5" "" "systemd 254" "environment.d"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
environment.d \- Definition of user service environment
.SH "SYNOPSIS"
.PP
~/\&.config/environment\&.d/*\&.conf
.PP
/etc/environment\&.d/*\&.conf
.PP
/run/environment\&.d/*\&.conf
.PP
/usr/lib/environment\&.d/*\&.conf
.PP
/etc/environment
.SH "DESCRIPTION"
.PP
Configuration files in the
environment\&.d/
directories contain lists of environment variable assignments passed to services started by the systemd user instance\&.
\fBsystemd-environment-d-generator\fR(8)
parses them and updates the environment exported by the systemd user instance\&. See below for an discussion of which processes inherit those variables\&.
.PP
It is recommended to use numerical prefixes for file names to simplify ordering\&.
.PP
For backwards compatibility, a symlink to
/etc/environment
is installed, so this file is also parsed\&.
.SH "CONFIGURATION DIRECTORIES AND PRECEDENCE"
.PP
Configuration files are read from directories in
/etc/,
/run/,
/usr/local/lib/, and
/lib/, in order of precedence, as listed in the SYNOPSIS section above\&. Files must have the
"\&.conf"
extension\&. Files in
/etc/
override files with the same name in
/run/,
/usr/local/lib/, and
/lib/\&. Files in
/run/
override files with the same name under
/usr/\&.
.PP
All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in\&. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence\&. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later)\&.
.PP
Packages should install their configuration files in
/usr/lib/
(distribution packages) or
/usr/local/lib/
(local installs)\&. Files in
/etc/
are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages\&. It is recommended to prefix all filenames with a two\-digit number and a dash, to simplify the ordering of the files\&.
.PP
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to
/dev/null
in the configuration directory in
/etc/, with the same filename as the vendor configuration file\&. If the vendor configuration file is included in the initrd image, the image has to be regenerated\&.
.SH "CONFIGURATION FORMAT"
.PP
The configuration files contain a list of
"\fIKEY\fR=\fIVALUE\fR"
environment variable assignments, separated by newlines\&. The right hand side of these assignments may reference previously defined environment variables, using the
"${OTHER_KEY}"
and
"$OTHER_KEY"
format\&. It is also possible to use
"${\fIFOO\fR:\-\fIDEFAULT_VALUE\fR}"
to expand in the same way as
"${\fIFOO\fR}"
unless the expansion would be empty, in which case it expands to
\fIDEFAULT_VALUE\fR, and use
"${\fIFOO\fR:+\fIALTERNATE_VALUE\fR}"
to expand to
\fIALTERNATE_VALUE\fR
as long as
"${\fIFOO\fR}"
would have expanded to a non\-empty value\&. No other elements of shell syntax are supported\&.
.PP
Each
\fIKEY\fR
must be a valid variable name\&. Empty lines and lines beginning with the comment character
"#"
are ignored\&.
.SS "Example"
.PP
\fBExample\ \&1.\ \&Setup environment to allow access to a program installed in /opt/foo\fR
.PP
/etc/environment\&.d/60\-foo\&.conf:
.sp
.if n \{\
.RS 4
.\}
.nf
        FOO_DEBUG=force\-software\-gl,log\-verbose
        PATH=/opt/foo/bin:$PATH
        LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
        XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:\-/usr/local/share/:/usr/share/}
        
.fi
.if n \{\
.RE
.\}
.SH "APPLICABILITY"
.PP
Environment variables exported by the user service manager (\fBsystemd \-\-user\fR
instance started in the
user@\fIuid\fR\&.service
system service) are passed to any services started by that service manager\&. In particular, this may include services which run user shells\&. For example in the GNOME environment, the graphical terminal emulator runs as the
gnome\-terminal\-server\&.service
user unit, which in turn runs the user shell, so that shell will inherit environment variables exported by the user manager\&. For other instances of the shell, not launched by the user service manager, the environment they inherit is defined by the program that starts them\&. Hint: in general,
\fBsystemd.service\fR(5)
units contain programs launched by systemd, and
\fBsystemd.scope\fR(5)
units contain programs launched by something else\&.
.PP
Note that these files do not affect the environment block of the service manager itself, but exclusively the environment blocks passed to the services it manages\&. Environment variables set that way thus cannot be used to influence behaviour of the service manager\&. In order to make changes to the service manager\*(Aqs environment block the environment must be modified before the user\*(Aqs service manager is invoked, for example from the system service manager or via a PAM module\&.
.PP
Specifically, for ssh logins, the
\fBsshd\fR(8)
service builds an environment that is a combination of variables forwarded from the remote system and defined by
\fBsshd\fR, see the discussion in
\fBssh\fR(1)\&. A graphical display session will have an analogous mechanism to define the environment\&. Note that some managers query the systemd user instance for the exported environment and inject this configuration into programs they start, using
\fBsystemctl show\-environment\fR
or the underlying D\-Bus call\&.
.SH "SEE ALSO"
.PP
\fBsystemd\fR(1),
\fBsystemd-environment-d-generator\fR(8),
\fBsystemd.environment-generator\fR(7)
